src/lib/tray-primary-progress.test.ts (1)

92-92: 💤 Low value

Consider explicitly asserting label: undefined for consistency.

Other updated test expectations in this file now explicitly include the label field (e.g., lines 166, 203, 241, 286). For consistency and clarity, this test should also assert label: undefined to make the expected output shape explicit when no data is available.

Proposed update for consistency

-  expect(bars).toEqual([{ id: "a", fraction: undefined }])
+  expect(bars).toEqual([{ id: "a", fraction: undefined, label: undefined }])

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/lib/tray-primary-progress.test.ts` at line 92, Update the test
expectation to explicitly include the label field so the shape matches other
assertions: change the toEqual assertion that checks bars (currently comparing
to [{ id: "a", fraction: undefined }]) to include label: undefined as well;
locate the assertion referencing bars in tray-primary-progress.test (the
expect(bars).toEqual(...) line) and add label: undefined to the expected object
to match the explicit expectations used elsewhere.

src/hooks/app/use-settings-display-actions.test.ts (1)

115-156: 💤 Low value

Consider adding menubar metric persistence failure coverage.

The "logs persistence failures" test verifies error logging for theme, display, reset timer, and time format save failures, but omits menubar metric. For consistency, consider adding a failure case for saveMenubarMetricMock and asserting the corresponding console.error call.

🧪 Proposed test extension

   it("logs persistence failures", async () => {
     const themeError = new Error("theme failed")
     const displayError = new Error("display failed")
     const resetError = new Error("reset failed")
+    const metricError = new Error("metric failed")
     const errorSpy = vi.spyOn(console, "error").mockImplementation(() => {})
     saveThemeModeMock.mockRejectedValueOnce(themeError)
     saveDisplayModeMock.mockRejectedValueOnce(displayError)
     saveResetTimerDisplayModeMock.mockRejectedValueOnce(resetError)
+    saveMenubarMetricMock.mockRejectedValueOnce(metricError)

     const timeFormatError = new Error("time format failed")
     saveTimeFormatModeMock.mockRejectedValueOnce(timeFormatError)

     const { result } = renderHook(() =>
       useSettingsDisplayActions({
         setThemeMode: vi.fn(),
         setDisplayMode: vi.fn(),
         resetTimerDisplayMode: "relative",
         setResetTimerDisplayMode: vi.fn(),
         setTimeFormatMode: vi.fn(),
         setMenubarIconStyle: vi.fn(),
         setMenubarMetric: vi.fn(),
         scheduleTrayIconUpdate: vi.fn(),
       })
     )

     act(() => {
       result.current.handleThemeModeChange("light")
       result.current.handleDisplayModeChange("left")
       result.current.handleResetTimerDisplayModeChange("relative")
       result.current.handleTimeFormatModeChange("12h")
+      result.current.handleMenubarMetricChange("weekly")
     })

     await waitFor(() => {
       expect(errorSpy).toHaveBeenCalledWith("Failed to save theme mode:", themeError)
       expect(errorSpy).toHaveBeenCalledWith("Failed to save display mode:", displayError)
       expect(errorSpy).toHaveBeenCalledWith("Failed to save reset timer display mode:", resetError)
       expect(errorSpy).toHaveBeenCalledWith("Failed to save time format mode:", timeFormatError)
+      expect(errorSpy).toHaveBeenCalledWith("Failed to save menubar metric:", metricError)
     })

     errorSpy.mockRestore()
   })

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/hooks/app/use-settings-display-actions.test.ts` around lines 115 - 156,
Add a failing persistence case for the menubar metric in the "logs persistence
failures" test: have saveMenubarMetricMock.mockRejectedValueOnce(new
Error("menubar metric failed")), invoke
result.current.handleMenubarMetricChange(...) inside the act block (use the same
pattern as handleThemeModeChange/handleDisplayModeChange), and add an
expectation in the waitFor that console.error was called with the matching
message ("Failed to save menubar metric:") and the error; this updates the test
around useSettingsDisplayActions, handleMenubarMetricChange, and
saveMenubarMetricMock to assert menubar metric failure logging.

docs/plugins/schema.md (1)

127-141: ⚡ Quick win

Consider clarifying that weekly lines may optionally have primaryOrder.

The docs state that "the provider must still define a primary (primaryOrder) line" but don't explicitly address whether the weekly line itself can have primaryOrder. Looking at the plugin configs:

• claude/plugin.json line 15: Weekly line has primaryOrder: 2 (serves as both weekly candidate and secondary primary)
• devin/plugin.json line 10: Weekly quota has primaryOrder: 1 (weekly IS the primary)
• codex/plugin.json line 15: Weekly line has NO primaryOrder (weekly-only, not a primary candidate)

All three patterns are valid and work correctly. A sentence clarifying "A weekly line may optionally include primaryOrder to also serve as a primary candidate" would eliminate ambiguity.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/plugins/schema.md` around lines 127 - 141, Add a clarifying sentence to
the Weekly Metric section: state that a line with "period": "weekly" may
optionally include a primaryOrder value to also serve as a primary candidate (so
a weekly line can be both the weekly override and count toward primary
ordering), and keep the existing rule that a provider must still define at least
one primaryOrder line to appear in the menubar; reference the JSON keys "lines",
"period", and "primaryOrder" when explaining this behavior and optionally
mention that plugin configs (e.g., claude/devin/codex patterns) show all three
valid patterns.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes